Skip to content

Add portable linux source build leg - #75546

Merged
mmitche merged 15 commits into
dotnet:mainfrom
mmitche:add-portable-linux-leg
Oct 6, 2022
Merged

Add portable linux source build leg#75546
mmitche merged 15 commits into
dotnet:mainfrom
mmitche:add-portable-linux-leg

Conversation

@mmitche

@mmitchemmitche commented Sep 13, 2022

Copy link
Copy Markdown
Member

Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.

While doing this, I cleaned up a couple parameters to make it clearer what they were doing

@mmitche
Add portable linux source build leg
72625f7
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@ghost

ghost commented Sep 13, 2022

Copy link
Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@ghostghost assigned mmitcheSep 13, 2022
@mmitche

mmitche commented Sep 13, 2022

Copy link
Copy Markdown
MemberAuthor

Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1991625&view=results

@mmitche

mmitche commented Sep 13, 2022

Copy link
Copy Markdown
MemberAuthor

Artifacts looked good except for the logs. Those had overlapping artifact names. Fixed that.

https://dev.azure.com/dnceng/internal/_build/results?buildId=1991830&view=results

@mmitche

mmitche commented Sep 13, 2022

Copy link
Copy Markdown
MemberAuthor

Getting closer here. Latest build looks correct except the publishing asset manifests need to have different names.

@mmitchemmitche closed this Sep 13, 2022
@mmitchemmitche reopened this Sep 13, 2022
hoyosjs
hoyosjs approved these changes Sep 14, 2022
View reviewed changes

@hoyosjshoyosjs left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM sans the manifest

Comment threadeng/pipelines/common/platform-matrix.yml
@mmitche

mmitche commented Sep 14, 2022

Copy link
Copy Markdown
MemberAuthor

Depends on dotnet/arcade#10860

@mmitche

mmitche commented Sep 20, 2022

Copy link
Copy Markdown
MemberAuthor

Depends on #75929 to add the right parameter to the common YAML step template.

@mmitche

mmitche commented Sep 20, 2022

Copy link
Copy Markdown
MemberAuthor

Updated arcade to get ahead on validation, and this should be the final official build test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1999350&view=results

@mmitche

mmitche commented Oct 3, 2022

Copy link
Copy Markdown
MemberAuthor

New official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2010326&view=results

@mmitche

mmitche commented Oct 3, 2022•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

@tmds@MichaelSimons I ended up reverting the change to use the banana RID here: bf026ca. I don't think this was correct, as it meant that runtime's official build was only producing source-build intermediates for the banana rid, which means that downstream repos could not actually consume these in their source-build legs.

I think the intention was to test a banana.blah RID (built on whatever container). if that's the case, maybe it makes sense to introduce an additional CI or PR (if it breaks enough) leg to validate these scenarios. But the official builds need to produce a real RID.

@tmds

tmds commented Oct 4, 2022

Copy link
Copy Markdown
Member

Yes, the goal is to verify you can build for an unknown rid.

This requires runtime to not use this rid while restoring artifacts, and to use it while naming output artifacts.

All other CI jobs use known rids, and in most cases the rid being restored is even the same as the one being built (like linux-x64 -> linux-x64). Then it goes unnoticed the builds are mixing up the output rid from the restore rid.

We should continue to have a CI job that builds an unknown rid, otherwise these mix-ups go undetected until they break source-build.

ViktorHofer
ViktorHofer reviewed Oct 4, 2022
View reviewed changes
Comment threadeng/pipelines/common/global-build-job.yml
buildScript: $(_sclEnableCommand) $(Build.SourcesDirectory)$(dir)build$(scriptExt)
nonPortable: true
# Use a custom RID that isn't in the RID graph here to validate we don't break the usage of custom rids that aren't in the graph.
targetRID: banana.24-x64

@ViktorHoferViktorHoferOct 4, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You remove the custom RID, but we want to keep it to make sure that we can build with arbitrary RIDs.

@mmitchemmitcheOct 4, 2022

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we probably need another leg, or one that only runs in PRs? Preference?

@mmitchemmitcheOct 4, 2022

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ViktorHofer@tmds@MichaelSimons I made some tweaks:

  • Build only linux-x64 portable officially (nothing else flows)
  • Add missing PR legs for linux-x64 (to avoid official breaks)
  • Add rolling CI for Banana and centos7

@mmitche

mmitche commented Oct 4, 2022

Copy link
Copy Markdown
MemberAuthor

Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2011400&view=results

@mmitche

mmitche commented Oct 5, 2022

Copy link
Copy Markdown
MemberAuthor

Outputs looking good. Any additional comments?

hoyosjs
hoyosjs approved these changes Oct 5, 2022
View reviewed changes
Comment threadeng/pipelines/global-build.yml Outdated
@build-analysisbuild-analysisBot mentioned this pull request Oct 6, 2022
Closed
@mmitche
mmitche merged commit b1f5113 into dotnet:mainOct 6, 2022
@mmitche
mmitche deleted the add-portable-linux-leg branch October 6, 2022 13:58
@ghostghost locked as resolved and limited conversation to collaborators Nov 5, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@ViktorHoferViktorHoferViktorHofer left review comments
@hoyosjshoyosjshoyosjs approved these changes
@MichaelSimonsMichaelSimonsAwaiting requested review from MichaelSimons
@jkoritzinskyjkoritzinskyAwaiting requested review from jkoritzinsky

Assignees

@mmitchemmitche

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@mmitche@tmds@ViktorHofer@hoyosjs
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Add portable linux source build leg by mmitche · Pull Request #75546 · dotnet/runtime · GitHub
Skip to content
Add portable linux source build leg - #75546
Merged
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Oct 6, 2022
Merged
Add portable linux source build leg#75546
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Conversation
@mmitche
@mmitchemmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

Member
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@mmitche
Add portable linux source build leg
72625f7
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@ghost
ghost
commented
Sep 13, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned mmitcheSep 13, 2022
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1991625&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Artifacts looked good except for the logs. Those had overlapping artifact names. Fixed that.
https://dev.azure.com/dnceng/internal/_build/results?buildId=1991830&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Getting closer here. Latest build looks correct except the publishing asset manifests need to have different names.
@mmitchemmitche
closed this
Sep 13, 2022
@mmitchemmitche
reopened this
Sep 13, 2022
hoyosjs
hoyosjs
approved these changes
Sep 14, 2022
View reviewed changes
@hoyosjshoyosjs
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM sans the manifest
Comment threadeng/pipelines/common/platform-matrix.yml
@mmitche
mmitche
commented
Sep 14, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on dotnet/arcade#10860
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on #75929 to add the right parameter to the common YAML step template.
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Updated arcade to get ahead on validation, and this should be the final official build test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1999350&view=results
@mmitche
mmitche
commented
Oct 3, 2022

Copy link


Copy Markdown

MemberAuthor
New official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2010326&view=results
@mmitche
mmitche
commented
Oct 3, 2022•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@tmds@MichaelSimons I ended up reverting the change to use the banana RID here: bf026ca. I don't think this was correct, as it meant that runtime's official build was only producing source-build intermediates for the banana rid, which means that downstream repos could not actually consume these in their source-build legs.
I think the intention was to test a banana.blah RID (built on whatever container). if that's the case, maybe it makes sense to introduce an additional CI or PR (if it breaks enough) leg to validate these scenarios. But the official builds need to produce a real RID.
@tmds
tmds
commented
Oct 4, 2022

Copy link


Copy Markdown

Member
Yes, the goal is to verify you can build for an unknown rid.
This requires runtime to not use this rid while restoring artifacts, and to use it while naming output artifacts.
All other CI jobs use known rids, and in most cases the rid being restored is even the same as the one being built (like linux-x64 -> linux-x64). Then it goes unnoticed the builds are mixing up the output rid from the restore rid.
We should continue to have a CI job that builds an unknown rid, otherwise these mix-ups go undetected until they break source-build.
ViktorHofer
ViktorHofer
reviewed
Oct 4, 2022
View reviewed changes
Comment threadeng/pipelines/common/global-build-job.yml
 buildScript: $(_sclEnableCommand) $(Build.SourcesDirectory)$(dir)build$(scriptExt)
 nonPortable: true
 # Use a custom RID that isn't in the RID graph here to validate we don't break the usage of custom rids that aren't in the graph.
 targetRID: banana.24-x64
@ViktorHoferViktorHoferOct 4, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You remove the custom RID, but we want to keep it to make sure that we can build with arbitrary RIDs.
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we probably need another leg, or one that only runs in PRs? Preference?
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ViktorHofer@tmds@MichaelSimons I made some tweaks:
  • Build only linux-x64 portable officially (nothing else flows)
  • Add missing PR legs for linux-x64 (to avoid official breaks)
  • Add rolling CI for Banana and centos7
@mmitche
mmitche
commented
Oct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2011400&view=results
@mmitche
mmitche
commented
Oct 5, 2022

Copy link


Copy Markdown

MemberAuthor
Outputs looking good. Any additional comments?
hoyosjs
hoyosjs
approved these changes
Oct 5, 2022
View reviewed changes
Comment threadeng/pipelines/global-build.yml
Outdated

@build-analysisbuild-analysisBot
mentioned this pull request
Oct 6, 2022

Closed

@mmitche
mmitche
merged commit b1f5113
into
dotnet:mainOct 6, 2022
@mmitche
mmitche
deleted the

add-portable-linux-leg

branch
October 6, 2022 13:58
@ghostghost
locked as resolved and limited conversation to collaborators
Nov 5, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@ViktorHoferViktorHoferViktorHofer left review comments
@hoyosjshoyosjshoyosjs approved these changes
@MichaelSimonsMichaelSimonsAwaiting requested review from MichaelSimons
@jkoritzinskyjkoritzinskyAwaiting requested review from jkoritzinsky

Assignees

@mmitchemmitche

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@mmitche@tmds@ViktorHofer@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add portable linux source build leg by mmitche · Pull Request #75546 · dotnet/runtime · GitHub
Skip to content
Add portable linux source build leg - #75546
Merged
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Oct 6, 2022
Merged
Add portable linux source build leg#75546
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Conversation
@mmitche
@mmitchemmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

Member
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@mmitche
Add portable linux source build leg
72625f7
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@ghost
ghost
commented
Sep 13, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned mmitcheSep 13, 2022
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1991625&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Artifacts looked good except for the logs. Those had overlapping artifact names. Fixed that.
https://dev.azure.com/dnceng/internal/_build/results?buildId=1991830&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Getting closer here. Latest build looks correct except the publishing asset manifests need to have different names.
@mmitchemmitche
closed this
Sep 13, 2022
@mmitchemmitche
reopened this
Sep 13, 2022
hoyosjs
hoyosjs
approved these changes
Sep 14, 2022
View reviewed changes
@hoyosjshoyosjs
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM sans the manifest
Comment threadeng/pipelines/common/platform-matrix.yml
@mmitche
mmitche
commented
Sep 14, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on dotnet/arcade#10860
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on #75929 to add the right parameter to the common YAML step template.
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Updated arcade to get ahead on validation, and this should be the final official build test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1999350&view=results
@mmitche
mmitche
commented
Oct 3, 2022

Copy link


Copy Markdown

MemberAuthor
New official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2010326&view=results
@mmitche
mmitche
commented
Oct 3, 2022•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@tmds@MichaelSimons I ended up reverting the change to use the banana RID here: bf026ca. I don't think this was correct, as it meant that runtime's official build was only producing source-build intermediates for the banana rid, which means that downstream repos could not actually consume these in their source-build legs.
I think the intention was to test a banana.blah RID (built on whatever container). if that's the case, maybe it makes sense to introduce an additional CI or PR (if it breaks enough) leg to validate these scenarios. But the official builds need to produce a real RID.
@tmds
tmds
commented
Oct 4, 2022

Copy link


Copy Markdown

Member
Yes, the goal is to verify you can build for an unknown rid.
This requires runtime to not use this rid while restoring artifacts, and to use it while naming output artifacts.
All other CI jobs use known rids, and in most cases the rid being restored is even the same as the one being built (like linux-x64 -> linux-x64). Then it goes unnoticed the builds are mixing up the output rid from the restore rid.
We should continue to have a CI job that builds an unknown rid, otherwise these mix-ups go undetected until they break source-build.
ViktorHofer
ViktorHofer
reviewed
Oct 4, 2022
View reviewed changes
Comment threadeng/pipelines/common/global-build-job.yml
 buildScript: $(_sclEnableCommand) $(Build.SourcesDirectory)$(dir)build$(scriptExt)
 nonPortable: true
 # Use a custom RID that isn't in the RID graph here to validate we don't break the usage of custom rids that aren't in the graph.
 targetRID: banana.24-x64
@ViktorHoferViktorHoferOct 4, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You remove the custom RID, but we want to keep it to make sure that we can build with arbitrary RIDs.
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we probably need another leg, or one that only runs in PRs? Preference?
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ViktorHofer@tmds@MichaelSimons I made some tweaks:
  • Build only linux-x64 portable officially (nothing else flows)
  • Add missing PR legs for linux-x64 (to avoid official breaks)
  • Add rolling CI for Banana and centos7
@mmitche
mmitche
commented
Oct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2011400&view=results
@mmitche
mmitche
commented
Oct 5, 2022

Copy link


Copy Markdown

MemberAuthor
Outputs looking good. Any additional comments?
hoyosjs
hoyosjs
approved these changes
Oct 5, 2022
View reviewed changes
Comment threadeng/pipelines/global-build.yml
Outdated

@build-analysisbuild-analysisBot
mentioned this pull request
Oct 6, 2022

Closed

@mmitche
mmitche
merged commit b1f5113
into
dotnet:mainOct 6, 2022
@mmitche
mmitche
deleted the

add-portable-linux-leg

branch
October 6, 2022 13:58
@ghostghost
locked as resolved and limited conversation to collaborators
Nov 5, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@ViktorHoferViktorHoferViktorHofer left review comments
@hoyosjshoyosjshoyosjs approved these changes
@MichaelSimonsMichaelSimonsAwaiting requested review from MichaelSimons
@jkoritzinskyjkoritzinskyAwaiting requested review from jkoritzinsky

Assignees

@mmitchemmitche

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@mmitche@tmds@ViktorHofer@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add portable linux source build leg by mmitche · Pull Request #75546 · dotnet/runtime · GitHub
Skip to content
Add portable linux source build leg - #75546
Merged
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Oct 6, 2022
Merged
Add portable linux source build leg#75546
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Conversation
@mmitche
@mmitchemmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

Member
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@mmitche
Add portable linux source build leg
72625f7
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@ghost
ghost
commented
Sep 13, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned mmitcheSep 13, 2022
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1991625&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Artifacts looked good except for the logs. Those had overlapping artifact names. Fixed that.
https://dev.azure.com/dnceng/internal/_build/results?buildId=1991830&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Getting closer here. Latest build looks correct except the publishing asset manifests need to have different names.
@mmitchemmitche
closed this
Sep 13, 2022
@mmitchemmitche
reopened this
Sep 13, 2022
hoyosjs
hoyosjs
approved these changes
Sep 14, 2022
View reviewed changes
@hoyosjshoyosjs
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM sans the manifest
Comment threadeng/pipelines/common/platform-matrix.yml
@mmitche
mmitche
commented
Sep 14, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on dotnet/arcade#10860
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on #75929 to add the right parameter to the common YAML step template.
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Updated arcade to get ahead on validation, and this should be the final official build test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1999350&view=results
@mmitche
mmitche
commented
Oct 3, 2022

Copy link


Copy Markdown

MemberAuthor
New official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2010326&view=results
@mmitche
mmitche
commented
Oct 3, 2022•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@tmds@MichaelSimons I ended up reverting the change to use the banana RID here: bf026ca. I don't think this was correct, as it meant that runtime's official build was only producing source-build intermediates for the banana rid, which means that downstream repos could not actually consume these in their source-build legs.
I think the intention was to test a banana.blah RID (built on whatever container). if that's the case, maybe it makes sense to introduce an additional CI or PR (if it breaks enough) leg to validate these scenarios. But the official builds need to produce a real RID.
@tmds
tmds
commented
Oct 4, 2022

Copy link


Copy Markdown

Member
Yes, the goal is to verify you can build for an unknown rid.
This requires runtime to not use this rid while restoring artifacts, and to use it while naming output artifacts.
All other CI jobs use known rids, and in most cases the rid being restored is even the same as the one being built (like linux-x64 -> linux-x64). Then it goes unnoticed the builds are mixing up the output rid from the restore rid.
We should continue to have a CI job that builds an unknown rid, otherwise these mix-ups go undetected until they break source-build.
ViktorHofer
ViktorHofer
reviewed
Oct 4, 2022
View reviewed changes
Comment threadeng/pipelines/common/global-build-job.yml
 buildScript: $(_sclEnableCommand) $(Build.SourcesDirectory)$(dir)build$(scriptExt)
 nonPortable: true
 # Use a custom RID that isn't in the RID graph here to validate we don't break the usage of custom rids that aren't in the graph.
 targetRID: banana.24-x64
@ViktorHoferViktorHoferOct 4, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You remove the custom RID, but we want to keep it to make sure that we can build with arbitrary RIDs.
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we probably need another leg, or one that only runs in PRs? Preference?
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ViktorHofer@tmds@MichaelSimons I made some tweaks:
  • Build only linux-x64 portable officially (nothing else flows)
  • Add missing PR legs for linux-x64 (to avoid official breaks)
  • Add rolling CI for Banana and centos7
@mmitche
mmitche
commented
Oct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2011400&view=results
@mmitche
mmitche
commented
Oct 5, 2022

Copy link


Copy Markdown

MemberAuthor
Outputs looking good. Any additional comments?
hoyosjs
hoyosjs
approved these changes
Oct 5, 2022
View reviewed changes
Comment threadeng/pipelines/global-build.yml
Outdated

@build-analysisbuild-analysisBot
mentioned this pull request
Oct 6, 2022

Closed

@mmitche
mmitche
merged commit b1f5113
into
dotnet:mainOct 6, 2022
@mmitche
mmitche
deleted the

add-portable-linux-leg

branch
October 6, 2022 13:58
@ghostghost
locked as resolved and limited conversation to collaborators
Nov 5, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@ViktorHoferViktorHoferViktorHofer left review comments
@hoyosjshoyosjshoyosjs approved these changes
@MichaelSimonsMichaelSimonsAwaiting requested review from MichaelSimons
@jkoritzinskyjkoritzinskyAwaiting requested review from jkoritzinsky

Assignees

@mmitchemmitche

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@mmitche@tmds@ViktorHofer@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Add portable linux source build leg by mmitche · Pull Request #75546 · dotnet/runtime · GitHub
Skip to content
Add portable linux source build leg - #75546
Merged
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Oct 6, 2022
Merged
Add portable linux source build leg#75546
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Conversation
@mmitche
@mmitchemmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

Member
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@mmitche
Add portable linux source build leg
72625f7
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@ghost
ghost
commented
Sep 13, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned mmitcheSep 13, 2022
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1991625&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Artifacts looked good except for the logs. Those had overlapping artifact names. Fixed that.
https://dev.azure.com/dnceng/internal/_build/results?buildId=1991830&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Getting closer here. Latest build looks correct except the publishing asset manifests need to have different names.
@mmitchemmitche
closed this
Sep 13, 2022
@mmitchemmitche
reopened this
Sep 13, 2022
hoyosjs
hoyosjs
approved these changes
Sep 14, 2022
View reviewed changes
@hoyosjshoyosjs
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM sans the manifest
Comment threadeng/pipelines/common/platform-matrix.yml
@mmitche
mmitche
commented
Sep 14, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on dotnet/arcade#10860
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on #75929 to add the right parameter to the common YAML step template.
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Updated arcade to get ahead on validation, and this should be the final official build test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1999350&view=results
@mmitche
mmitche
commented
Oct 3, 2022

Copy link


Copy Markdown

MemberAuthor
New official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2010326&view=results
@mmitche
mmitche
commented
Oct 3, 2022•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@tmds@MichaelSimons I ended up reverting the change to use the banana RID here: bf026ca. I don't think this was correct, as it meant that runtime's official build was only producing source-build intermediates for the banana rid, which means that downstream repos could not actually consume these in their source-build legs.
I think the intention was to test a banana.blah RID (built on whatever container). if that's the case, maybe it makes sense to introduce an additional CI or PR (if it breaks enough) leg to validate these scenarios. But the official builds need to produce a real RID.
@tmds
tmds
commented
Oct 4, 2022

Copy link


Copy Markdown

Member
Yes, the goal is to verify you can build for an unknown rid.
This requires runtime to not use this rid while restoring artifacts, and to use it while naming output artifacts.
All other CI jobs use known rids, and in most cases the rid being restored is even the same as the one being built (like linux-x64 -> linux-x64). Then it goes unnoticed the builds are mixing up the output rid from the restore rid.
We should continue to have a CI job that builds an unknown rid, otherwise these mix-ups go undetected until they break source-build.
ViktorHofer
ViktorHofer
reviewed
Oct 4, 2022
View reviewed changes
Comment threadeng/pipelines/common/global-build-job.yml
 buildScript: $(_sclEnableCommand) $(Build.SourcesDirectory)$(dir)build$(scriptExt)
 nonPortable: true
 # Use a custom RID that isn't in the RID graph here to validate we don't break the usage of custom rids that aren't in the graph.
 targetRID: banana.24-x64
@ViktorHoferViktorHoferOct 4, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You remove the custom RID, but we want to keep it to make sure that we can build with arbitrary RIDs.
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we probably need another leg, or one that only runs in PRs? Preference?
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ViktorHofer@tmds@MichaelSimons I made some tweaks:
  • Build only linux-x64 portable officially (nothing else flows)
  • Add missing PR legs for linux-x64 (to avoid official breaks)
  • Add rolling CI for Banana and centos7
@mmitche
mmitche
commented
Oct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2011400&view=results
@mmitche
mmitche
commented
Oct 5, 2022

Copy link


Copy Markdown

MemberAuthor
Outputs looking good. Any additional comments?
hoyosjs
hoyosjs
approved these changes
Oct 5, 2022
View reviewed changes
Comment threadeng/pipelines/global-build.yml
Outdated

@build-analysisbuild-analysisBot
mentioned this pull request
Oct 6, 2022

Closed

@mmitche
mmitche
merged commit b1f5113
into
dotnet:mainOct 6, 2022
@mmitche
mmitche
deleted the

add-portable-linux-leg

branch
October 6, 2022 13:58
@ghostghost
locked as resolved and limited conversation to collaborators
Nov 5, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@ViktorHoferViktorHoferViktorHofer left review comments
@hoyosjshoyosjshoyosjs approved these changes
@MichaelSimonsMichaelSimonsAwaiting requested review from MichaelSimons
@jkoritzinskyjkoritzinskyAwaiting requested review from jkoritzinsky

Assignees

@mmitchemmitche

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@mmitche@tmds@ViktorHofer@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add portable linux source build leg by mmitche · Pull Request #75546 · dotnet/runtime · GitHub
Skip to content
Add portable linux source build leg - #75546
Merged
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Oct 6, 2022
Merged
Add portable linux source build leg#75546
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Conversation
@mmitche
@mmitchemmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

Member
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@mmitche
Add portable linux source build leg
72625f7
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@ghost
ghost
commented
Sep 13, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned mmitcheSep 13, 2022
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1991625&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Artifacts looked good except for the logs. Those had overlapping artifact names. Fixed that.
https://dev.azure.com/dnceng/internal/_build/results?buildId=1991830&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Getting closer here. Latest build looks correct except the publishing asset manifests need to have different names.
@mmitchemmitche
closed this
Sep 13, 2022
@mmitchemmitche
reopened this
Sep 13, 2022
hoyosjs
hoyosjs
approved these changes
Sep 14, 2022
View reviewed changes
@hoyosjshoyosjs
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM sans the manifest
Comment threadeng/pipelines/common/platform-matrix.yml
@mmitche
mmitche
commented
Sep 14, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on dotnet/arcade#10860
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on #75929 to add the right parameter to the common YAML step template.
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Updated arcade to get ahead on validation, and this should be the final official build test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1999350&view=results
@mmitche
mmitche
commented
Oct 3, 2022

Copy link


Copy Markdown

MemberAuthor
New official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2010326&view=results
@mmitche
mmitche
commented
Oct 3, 2022•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@tmds@MichaelSimons I ended up reverting the change to use the banana RID here: bf026ca. I don't think this was correct, as it meant that runtime's official build was only producing source-build intermediates for the banana rid, which means that downstream repos could not actually consume these in their source-build legs.
I think the intention was to test a banana.blah RID (built on whatever container). if that's the case, maybe it makes sense to introduce an additional CI or PR (if it breaks enough) leg to validate these scenarios. But the official builds need to produce a real RID.
@tmds
tmds
commented
Oct 4, 2022

Copy link


Copy Markdown

Member
Yes, the goal is to verify you can build for an unknown rid.
This requires runtime to not use this rid while restoring artifacts, and to use it while naming output artifacts.
All other CI jobs use known rids, and in most cases the rid being restored is even the same as the one being built (like linux-x64 -> linux-x64). Then it goes unnoticed the builds are mixing up the output rid from the restore rid.
We should continue to have a CI job that builds an unknown rid, otherwise these mix-ups go undetected until they break source-build.
ViktorHofer
ViktorHofer
reviewed
Oct 4, 2022
View reviewed changes
Comment threadeng/pipelines/common/global-build-job.yml
 buildScript: $(_sclEnableCommand) $(Build.SourcesDirectory)$(dir)build$(scriptExt)
 nonPortable: true
 # Use a custom RID that isn't in the RID graph here to validate we don't break the usage of custom rids that aren't in the graph.
 targetRID: banana.24-x64
@ViktorHoferViktorHoferOct 4, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You remove the custom RID, but we want to keep it to make sure that we can build with arbitrary RIDs.
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we probably need another leg, or one that only runs in PRs? Preference?
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ViktorHofer@tmds@MichaelSimons I made some tweaks:
  • Build only linux-x64 portable officially (nothing else flows)
  • Add missing PR legs for linux-x64 (to avoid official breaks)
  • Add rolling CI for Banana and centos7
@mmitche
mmitche
commented
Oct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2011400&view=results
@mmitche
mmitche
commented
Oct 5, 2022

Copy link


Copy Markdown

MemberAuthor
Outputs looking good. Any additional comments?
hoyosjs
hoyosjs
approved these changes
Oct 5, 2022
View reviewed changes
Comment threadeng/pipelines/global-build.yml
Outdated

@build-analysisbuild-analysisBot
mentioned this pull request
Oct 6, 2022

Closed

@mmitche
mmitche
merged commit b1f5113
into
dotnet:mainOct 6, 2022
@mmitche
mmitche
deleted the

add-portable-linux-leg

branch
October 6, 2022 13:58
@ghostghost
locked as resolved and limited conversation to collaborators
Nov 5, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@ViktorHoferViktorHoferViktorHofer left review comments
@hoyosjshoyosjshoyosjs approved these changes
@MichaelSimonsMichaelSimonsAwaiting requested review from MichaelSimons
@jkoritzinskyjkoritzinskyAwaiting requested review from jkoritzinsky

Assignees

@mmitchemmitche

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@mmitche@tmds@ViktorHofer@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add portable linux source build leg by mmitche · Pull Request #75546 · dotnet/runtime · GitHub
Skip to content
Add portable linux source build leg - #75546
Merged
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Oct 6, 2022
Merged
Add portable linux source build leg#75546
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Conversation
@mmitche
@mmitchemmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

Member
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@mmitche
Add portable linux source build leg
72625f7
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@ghost
ghost
commented
Sep 13, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned mmitcheSep 13, 2022
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1991625&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Artifacts looked good except for the logs. Those had overlapping artifact names. Fixed that.
https://dev.azure.com/dnceng/internal/_build/results?buildId=1991830&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Getting closer here. Latest build looks correct except the publishing asset manifests need to have different names.
@mmitchemmitche
closed this
Sep 13, 2022
@mmitchemmitche
reopened this
Sep 13, 2022
hoyosjs
hoyosjs
approved these changes
Sep 14, 2022
View reviewed changes
@hoyosjshoyosjs
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM sans the manifest
Comment threadeng/pipelines/common/platform-matrix.yml
@mmitche
mmitche
commented
Sep 14, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on dotnet/arcade#10860
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on #75929 to add the right parameter to the common YAML step template.
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Updated arcade to get ahead on validation, and this should be the final official build test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1999350&view=results
@mmitche
mmitche
commented
Oct 3, 2022

Copy link


Copy Markdown

MemberAuthor
New official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2010326&view=results
@mmitche
mmitche
commented
Oct 3, 2022•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@tmds@MichaelSimons I ended up reverting the change to use the banana RID here: bf026ca. I don't think this was correct, as it meant that runtime's official build was only producing source-build intermediates for the banana rid, which means that downstream repos could not actually consume these in their source-build legs.
I think the intention was to test a banana.blah RID (built on whatever container). if that's the case, maybe it makes sense to introduce an additional CI or PR (if it breaks enough) leg to validate these scenarios. But the official builds need to produce a real RID.
@tmds
tmds
commented
Oct 4, 2022

Copy link


Copy Markdown

Member
Yes, the goal is to verify you can build for an unknown rid.
This requires runtime to not use this rid while restoring artifacts, and to use it while naming output artifacts.
All other CI jobs use known rids, and in most cases the rid being restored is even the same as the one being built (like linux-x64 -> linux-x64). Then it goes unnoticed the builds are mixing up the output rid from the restore rid.
We should continue to have a CI job that builds an unknown rid, otherwise these mix-ups go undetected until they break source-build.
ViktorHofer
ViktorHofer
reviewed
Oct 4, 2022
View reviewed changes
Comment threadeng/pipelines/common/global-build-job.yml
 buildScript: $(_sclEnableCommand) $(Build.SourcesDirectory)$(dir)build$(scriptExt)
 nonPortable: true
 # Use a custom RID that isn't in the RID graph here to validate we don't break the usage of custom rids that aren't in the graph.
 targetRID: banana.24-x64
@ViktorHoferViktorHoferOct 4, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You remove the custom RID, but we want to keep it to make sure that we can build with arbitrary RIDs.
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we probably need another leg, or one that only runs in PRs? Preference?
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ViktorHofer@tmds@MichaelSimons I made some tweaks:
  • Build only linux-x64 portable officially (nothing else flows)
  • Add missing PR legs for linux-x64 (to avoid official breaks)
  • Add rolling CI for Banana and centos7
@mmitche
mmitche
commented
Oct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2011400&view=results
@mmitche
mmitche
commented
Oct 5, 2022

Copy link


Copy Markdown

MemberAuthor
Outputs looking good. Any additional comments?
hoyosjs
hoyosjs
approved these changes
Oct 5, 2022
View reviewed changes
Comment threadeng/pipelines/global-build.yml
Outdated

@build-analysisbuild-analysisBot
mentioned this pull request
Oct 6, 2022

Closed

@mmitche
mmitche
merged commit b1f5113
into
dotnet:mainOct 6, 2022
@mmitche
mmitche
deleted the

add-portable-linux-leg

branch
October 6, 2022 13:58
@ghostghost
locked as resolved and limited conversation to collaborators
Nov 5, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@ViktorHoferViktorHoferViktorHofer left review comments
@hoyosjshoyosjshoyosjs approved these changes
@MichaelSimonsMichaelSimonsAwaiting requested review from MichaelSimons
@jkoritzinskyjkoritzinskyAwaiting requested review from jkoritzinsky

Assignees

@mmitchemmitche

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@mmitche@tmds@ViktorHofer@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Add portable linux source build leg by mmitche · Pull Request #75546 · dotnet/runtime · GitHub
Skip to content
Add portable linux source build leg - #75546
Merged
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Oct 6, 2022
Merged
Add portable linux source build leg#75546
mmitche merged 15 commits into
dotnet:mainfrom 
mmitche:add-portable-linux-leg
Conversation
@mmitche
@mmitchemmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

Member
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@mmitche
Add portable linux source build leg
72625f7
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing
@ghost
ghost
commented
Sep 13, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned mmitcheSep 13, 2022
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1991625&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Artifacts looked good except for the logs. Those had overlapping artifact names. Fixed that.
https://dev.azure.com/dnceng/internal/_build/results?buildId=1991830&view=results
@mmitche
mmitche
commented
Sep 13, 2022

Copy link


Copy Markdown

MemberAuthor
Getting closer here. Latest build looks correct except the publishing asset manifests need to have different names.
@mmitchemmitche
closed this
Sep 13, 2022
@mmitchemmitche
reopened this
Sep 13, 2022
hoyosjs
hoyosjs
approved these changes
Sep 14, 2022
View reviewed changes
@hoyosjshoyosjs
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM sans the manifest
Comment threadeng/pipelines/common/platform-matrix.yml
@mmitche
mmitche
commented
Sep 14, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on dotnet/arcade#10860
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Depends on #75929 to add the right parameter to the common YAML step template.
@mmitche
mmitche
commented
Sep 20, 2022

Copy link


Copy Markdown

MemberAuthor
Updated arcade to get ahead on validation, and this should be the final official build test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1999350&view=results
@mmitche
mmitche
commented
Oct 3, 2022

Copy link


Copy Markdown

MemberAuthor
New official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2010326&view=results
@mmitche
mmitche
commented
Oct 3, 2022•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@tmds@MichaelSimons I ended up reverting the change to use the banana RID here: bf026ca. I don't think this was correct, as it meant that runtime's official build was only producing source-build intermediates for the banana rid, which means that downstream repos could not actually consume these in their source-build legs.
I think the intention was to test a banana.blah RID (built on whatever container). if that's the case, maybe it makes sense to introduce an additional CI or PR (if it breaks enough) leg to validate these scenarios. But the official builds need to produce a real RID.
@tmds
tmds
commented
Oct 4, 2022

Copy link


Copy Markdown

Member
Yes, the goal is to verify you can build for an unknown rid.
This requires runtime to not use this rid while restoring artifacts, and to use it while naming output artifacts.
All other CI jobs use known rids, and in most cases the rid being restored is even the same as the one being built (like linux-x64 -> linux-x64). Then it goes unnoticed the builds are mixing up the output rid from the restore rid.
We should continue to have a CI job that builds an unknown rid, otherwise these mix-ups go undetected until they break source-build.
ViktorHofer
ViktorHofer
reviewed
Oct 4, 2022
View reviewed changes
Comment threadeng/pipelines/common/global-build-job.yml
 buildScript: $(_sclEnableCommand) $(Build.SourcesDirectory)$(dir)build$(scriptExt)
 nonPortable: true
 # Use a custom RID that isn't in the RID graph here to validate we don't break the usage of custom rids that aren't in the graph.
 targetRID: banana.24-x64
@ViktorHoferViktorHoferOct 4, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You remove the custom RID, but we want to keep it to make sure that we can build with arbitrary RIDs.
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we probably need another leg, or one that only runs in PRs? Preference?
@mmitchemmitcheOct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ViktorHofer@tmds@MichaelSimons I made some tweaks:
  • Build only linux-x64 portable officially (nothing else flows)
  • Add missing PR legs for linux-x64 (to avoid official breaks)
  • Add rolling CI for Banana and centos7
@mmitche
mmitche
commented
Oct 4, 2022

Copy link


Copy Markdown

MemberAuthor
Official test: https://dev.azure.com/dnceng/internal/_build/results?buildId=2011400&view=results
@mmitche
mmitche
commented
Oct 5, 2022

Copy link


Copy Markdown

MemberAuthor
Outputs looking good. Any additional comments?
hoyosjs
hoyosjs
approved these changes
Oct 5, 2022
View reviewed changes
Comment threadeng/pipelines/global-build.yml
Outdated

@build-analysisbuild-analysisBot
mentioned this pull request
Oct 6, 2022

Closed

@mmitche
mmitche
merged commit b1f5113
into
dotnet:mainOct 6, 2022
@mmitche
mmitche
deleted the

add-portable-linux-leg

branch
October 6, 2022 13:58
@ghostghost
locked as resolved and limited conversation to collaborators
Nov 5, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@ViktorHoferViktorHoferViktorHofer left review comments
@hoyosjshoyosjshoyosjs approved these changes
@MichaelSimonsMichaelSimonsAwaiting requested review from MichaelSimons
@jkoritzinskyjkoritzinskyAwaiting requested review from jkoritzinsky

Assignees

@mmitchemmitche

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@mmitche@tmds@ViktorHofer@hoyosjs