Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add nightly build on Github Actions #12491

Merged
merged 1 commit into from
May 20, 2021

Conversation

MoonlightSentinel
Copy link
Contributor

@MoonlightSentinel MoonlightSentinel commented Apr 30, 2021

Creates a new action that generates a new release for all currently
supported targets (linux, osx, windows, freebsd) on merges to master.

The release are generated by using build_all.d from installer


WIP because it contains the on: pull-request trigger for testing purposes

@MoonlightSentinel MoonlightSentinel force-pushed the nightlies branch 12 times, most recently from 202004f to a175781 Compare May 1, 2021 17:30
@maxhaton maxhaton changed the title Add nighly build on Github Actions Add nightly build on Github Actions May 1, 2021
@MoonlightSentinel MoonlightSentinel force-pushed the nightlies branch 17 times, most recently from 8fd68da to 420af4d Compare May 2, 2021 00:27
@Imperatorn
Copy link
Contributor

Any idea if godbolt also would be updated?

@MoonlightSentinel
Copy link
Contributor Author

MoonlightSentinel commented May 5, 2021

The current implementation only uploads nightlys to the release page. Future work could either adapt those tools to use GitHub or push the nightlies to dlang.org.

See #12150

@MoonlightSentinel MoonlightSentinel force-pushed the nightlies branch 3 times, most recently from 879f59a to 07c815f Compare May 5, 2021 12:55
Copy link
Contributor Author

@MoonlightSentinel MoonlightSentinel left a comment

Choose a reason for hiding this comment

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

Some thoughts / hints

# Rebuild on merges to master
push:
branches:
- master
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure if this is the best trigger. The workflow could also be a "real" nightly build to automatically include changes to druntime/phobos even when there are no changes to DMD. It also would save a lot of CI time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Switched to a daily build at 00:00 UTC

rpm \
rsync \
unzip \
xz-utils
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Some of those should already be included in the base image, but I've kept them just to be sure.


# Determine installed LDC version
LDC=$(ldc2 --version | head -n 1 | cut -d'(' -f2 | cut -d')' -f1)
echo "::set-output name=host_ldc::$LDC"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This automatically updates the host compiler with every LDC release.

#
- name: Create the nightly release
# Currently disabled due to missing permissions
if: ${{ false }}
Copy link
Contributor Author

@MoonlightSentinel MoonlightSentinel May 9, 2021

Choose a reason for hiding this comment

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

Doesn't work due to missing permissions because the PR was issued from a fork. Could probably be enabled by another PR from an upstream branch.

See the generated artifacts for a preview of the actual releases

@dlang-bot
Copy link
Contributor

Thanks for your pull request and interest in making D better, @MoonlightSentinel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.


If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#12491"

Creates a new action that generates a new release for all currently
supported targets (linux, osx, windows, freebsd) on merges to master.

The release are generated by using `build_all.d` from installer
@MoonlightSentinel MoonlightSentinel force-pushed the nightlies branch 2 times, most recently from 458d330 to c5f715c Compare May 18, 2021 21:10
@MoonlightSentinel
Copy link
Contributor Author

Dlang Bot is AWOL again?

@RazvanN7
Copy link
Contributor

RazvanN7 commented May 20, 2021

@CyberShadow is migrating the bot, so it will probably be offline a bit. I assume the auto-merge label does not work. Is it problematic if I manually merge this?

@thewilsonator thewilsonator merged commit 9443d84 into dlang:master May 20, 2021
@MoonlightSentinel MoonlightSentinel deleted the nightlies branch May 20, 2021 10:00
@MoonlightSentinel
Copy link
Contributor Author

@CyberShadow is migrating the bot, so it will probably be offline a bit. I assume the auto-merge label does not work.

Thanks for the info.

Is it problematic if I manually merge this?

No.


How do we enable the final step which creates the github release? I couldn't test that step due to insufficient permissions (because this PR originates from a fork).
Can you create a branch in this repo s.t. we can test it in another PR or should I simply enable it and check the results?

@RazvanN7
Copy link
Contributor

How do we enable the final step which creates the github release? I couldn't test that step due to insufficient permissions (because this PR originates from a fork).

I also don't have sufficient permissions.

should I simply enable it and check the results?

Go for it.

@CyberShadow
Copy link
Member

@CyberShadow is migrating the bot, so it will probably be offline a bit. I assume the auto-merge label does not work. Is it problematic if I manually merge this?

I don't think I've yet to do anything which would cause downtime, so that issue would be unrelated.

@CyberShadow
Copy link
Member

I noticed two issues which I think are caused by the way these nightlies are being made available:

  1. GitHub sends an email every few days about the nightly release
  2. The tag seems to be rewritten every time, causing git fetch to fail (because it refuses to overwrite the moved tag by default).

@MoonlightSentinel Would it be possible to use a different approach to this that would not have these issues?

The approach used by LDC may be better. Instead of creating a new release every time, instead they update an existing release. We also use a small server-side script to allow finding download URLs for the latest release binaries programmatically.

@Geod24
Copy link
Member

Geod24 commented Jun 10, 2021

  1. The workflow triggers in user's forks, which might be why you are getting the emails @CyberShadow ?

@CyberShadow
Copy link
Member

I don't think so. Here is what the email looks like:

@MoonlightSentinel
Copy link
Contributor Author

@MoonlightSentinel Would it be possible to use a different approach to this that would not have these issues?

The approach used by LDC may be better. Instead of creating a new release every time, instead they update an existing release.

I'm sorry for the inconvinience caused by the current implementation. Updating the attached assets should be possible by switching to a different action. I'll have a look.

We also use a small server-side script to allow finding download URLs for the latest release binaries programmatically.

Note that install.sh already supports these nightlies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants