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.

Sign up for GitHub

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

Jump to bottom

There should be periodic named releases. #91

Closed
Tracked by #7
aiuto opened this issue Nov 12, 2020 · 17 comments
Closed
Tracked by #7

There should be periodic named releases. #91

aiuto opened this issue Nov 12, 2020 · 17 comments

Comments

@aiuto
Copy link
Contributor

aiuto commented Nov 12, 2020

If there is no guidance about what commits are considered "good" (for various values of good), people will just use head. If people do that, debugging version skew problems is infeasible.
@olekw
Copy link
Contributor

olekw commented Dec 28, 2020

I'll also need an actual release to package properly for Debian. Is that feasible in the near-term? cc:@meteorcloudy

@meteorcloudy
Copy link
Member

/cc @oquenchil Can we make a release for rules_cc?

@aiuto
Copy link
Contributor Author

aiuto commented Jan 5, 2021

FWIW: After bazelbuild/bazel#12743 is merged, you should be able to update bazel to the new rules_cc with a 3 line change, single file change.

@meteorcloudy
Copy link
Member

@aiuto That's not what we are looking for. We want to package rules_cc into Debian, so that Bazel doesn't have to download it from internet at all. To do that, we need a release for this project.

@aiuto
Copy link
Contributor Author

aiuto commented Jan 7, 2021

@oquenchil @philwo

Ah.... I see a terminology difference. When we (Bazel) says release, we mean a versioned distribution archive that could be hosted on github. To you, that means a .deb package.

My concern was only about getting named versions to replace github hashes.
Getting from that to a .deb file in the right place will require answering some questions. Between us, I think we can come up with the answers. What we do for this will set a pattern/expectation for other rule sets to follow, so @philwo may want to chime in.

Questions and thoughts:

  • rules_pkg has .deb file building tools. We can add to that as needed.
  • Should the distribution be just source (essentially, all the files)?
  • Should we also have a binary distribution that excludes examples and tests?
  • Users will often need two versions installed at the same time when they are transitioning bazel versions.
    • install to /usr/share/bazelbuild/rules_cc/VERSION/...
    • in WORKSPACE
    local_repository(name="rules_cc", path="/usr/share/bazelbuild/rules_cc/VERSION/")
  • How do we get from bazel build //distro:rules_cc.deb to the Debian repository?
    • Should rules_pkg have scripts which aid in this?
    • Do we have to sign them? will someone need a secure pipeline for signing them?
    • Is it sufficient for the Bazel team to create the .deb file at the same time they do the versioned .tar file?

@meteorcloudy
Copy link
Member

Ah.... I see a terminology difference. When we (Bazel) says release, we mean a versioned distribution archive that could be hosted on github. To you, that means a .deb package.

No, what we want are the same, we also just need a versioned distribution archive, which is not available right now. @olekw will kindly help us create the deb package and get it into the Debian distribution.

The deb package will essentially only contains Bazel files. It would great if we can exclude unnecessary file in the release archive.

@oquenchil
Copy link
Contributor

I will create the release for rules_cc on GitHub, I was a bit hesitant because we deem rules_cc a mistake and we shouldn't have created it before finishing starlarkifying the rules. We don't plan on deleting the repository now because that would be a lot of hard work but we hope to spend as little time on the repo as possible in the short term.

I will document that the release is not part of an official process, there is no guaranteed release cycle and it just exists to support Debian packaging. I will name the first release 0.1.

@olekw
Copy link
Contributor

olekw commented Mar 25, 2021

@oquenchil That would be great! Any progress on that?

@olekw
Copy link
Contributor

olekw commented Apr 5, 2021

To clarify, we don't need a "binary" release to package this in Debian. We just need a source release since we build everything from source anyway. So just a "0.1.0" release tag would suffice for our purposes.

@olekw
Copy link
Contributor

olekw commented Apr 5, 2021

On a loosely-related question, what's the long-term plan, @oquenchil? Are you planning to refactor the code for rules_cc or just integrate that functionality directly into core Bazel?

@catleeball
Copy link

catleeball commented Apr 23, 2021 •
edited
Loading

I was a bit hesitant because we deem rules_cc a mistake and we shouldn't have created it before finishing starlarkifying the rules.

Do you know when the new starlark rules will be released? And will they replace the contents of this repository, or be uploaded elsewhere?

@aiuto aiuto mentioned this issue Jun 28, 2021
Open
copybara-service bot pushed a commit to google/XNNPACK that referenced this issue Jul 1, 2021
@xnnpack-bot
Update reference to rules_cc to main.zip. This is required by bazelbu…
5927478 
…ild/rules_cc#107

The longer term solution is:
- To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91)
- Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions.

PiperOrigin-RevId: 382526074
@copybara-service copybara-service bot mentioned this issue Jul 1, 2021
Merged
copybara-service bot pushed a commit to google/XNNPACK that referenced this issue Jul 1, 2021
@xnnpack-bot
Update reference to rules_cc to main.zip. This is required by bazelbu…
7c1e02c 
…ild/rules_cc#107

The longer term solution is:
- To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91)
- Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions.

PiperOrigin-RevId: 382526074
copybara-service bot pushed a commit to google/XNNPACK that referenced this issue Jul 1, 2021
@xnnpack-bot
Update reference to rules_cc to main.zip. This is required by bazelbu…
1514774 
…ild/rules_cc#107

The longer term solution is:
- To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91)
- Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions.

PiperOrigin-RevId: 382526074
copybara-service bot pushed a commit to google/XNNPACK that referenced this issue Jul 1, 2021
@xnnpack-bot
Update reference to rules_cc to main.zip. This is required by bazelbu…
e1c7fed 
…ild/rules_cc#107

The longer term solution is:
- To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91)
- Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions.

PiperOrigin-RevId: 382531776
copybara-service bot pushed a commit to google/XNNPACK that referenced this issue Jul 1, 2021
@xnnpack-bot
Update reference to rules_cc to main.zip. This is required by bazelbu…
78f98c1 
…ild/rules_cc#107

The longer term solution is:
- To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91)
- Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions.

PiperOrigin-RevId: 382544881
@copybara-service copybara-service bot mentioned this issue Jul 1, 2021
Merged
copybara-service bot pushed a commit to google/XNNPACK that referenced this issue Jul 1, 2021
@xnnpack-bot
Update reference to rules_cc to main.zip. This is required by bazelbu…
8eca65f 
…ild/rules_cc#107

The longer term solution is:
- To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91)
- Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions.

PiperOrigin-RevId: 382544881
copybara-service bot pushed a commit to google/XNNPACK that referenced this issue Jul 1, 2021
@xnnpack-bot
Update reference to rules_cc to main.zip. This is required by bazelbu…
366a6a5 
…ild/rules_cc#107

The longer term solution is:
- To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91)
- Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions.

PiperOrigin-RevId: 382544881
copybara-service bot pushed a commit to google/XNNPACK that referenced this issue Jul 1, 2021
@xnnpack-bot
Update reference to rules_cc to main.zip. This is required by bazelbu…
d2527c2 
…ild/rules_cc#107

The longer term solution is:
- To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91)
- Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions.

PiperOrigin-RevId: 382555074
@limdor limdor mentioned this issue Sep 6, 2021
Closed
limdor added a commit to limdor/rules_go that referenced this issue Sep 9, 2021
@limdor
Remove dependencie with bazelbuild/rules_cc
4728803 
Long time ago Bazel was saying that cc_binary, cc_library, cc_test and the other cc_* rules should be imported from rules_cc.
However rules_cc was always saying that there is no need to use them yet.
After several discussions it was clarified that migration to bazelbuild/rules_cc was put on hold and there is not need to the users that they start using it.
One of the reasons why a person would not want to use rules_cc right now is because there is no release and there is no notion of what is a good commit:
bazelbuild/rules_cc#91
bazelbuild/rules_cc#68

The fact that rules_go depends on rules_cc forces any rules_go user to use rules_cc. Considering that rules_docker depends on rules_go, any rules_docker user is also forced to depend on rules_cc.

More information about the discussions:
bazelbuild/rules_cc#86
bazelbuild/rules_cc#92
bazelbuild/buildtools#923
bazelbuild/buildtools#952

Fixes bazel-contrib#2949
@limdor limdor mentioned this issue Sep 9, 2021
Merged
limdor added a commit to limdor/rules_go that referenced this issue Sep 9, 2021
@limdor
Remove dependencie with bazelbuild/rules_cc
da28548 
Long time ago Bazel was saying that cc_binary, cc_library, cc_test and the other cc_* rules should be imported from rules_cc.
However rules_cc was always saying that there is no need to use them yet.
After several discussions it was clarified that migration to bazelbuild/rules_cc was put on hold and there is not need to the users that they start using it.
One of the reasons why a person would not want to use rules_cc right now is because there is no release and there is no notion of what is a good commit:
bazelbuild/rules_cc#91
bazelbuild/rules_cc#68

The fact that rules_go depends on rules_cc forces any rules_go user to use rules_cc. Considering that rules_docker depends on rules_go, any rules_docker user is also forced to depend on rules_cc.

More information about the discussions:
bazelbuild/rules_cc#86
bazelbuild/rules_cc#92
bazelbuild/buildtools#923
bazelbuild/buildtools#952

Fixes bazel-contrib#2949
achew22 pushed a commit to bazel-contrib/rules_go that referenced this issue Sep 10, 2021
@limdor
Remove dependencie with bazelbuild/rules_cc (#2950)
5efc3c2 
Long time ago Bazel was saying that cc_binary, cc_library, cc_test and the other cc_* rules should be imported from rules_cc.
However rules_cc was always saying that there is no need to use them yet.
After several discussions it was clarified that migration to bazelbuild/rules_cc was put on hold and there is not need to the users that they start using it.
One of the reasons why a person would not want to use rules_cc right now is because there is no release and there is no notion of what is a good commit:
bazelbuild/rules_cc#91
bazelbuild/rules_cc#68

The fact that rules_go depends on rules_cc forces any rules_go user to use rules_cc. Considering that rules_docker depends on rules_go, any rules_docker user is also forced to depend on rules_cc.

More information about the discussions:
bazelbuild/rules_cc#86
bazelbuild/rules_cc#92
bazelbuild/buildtools#923
bazelbuild/buildtools#952

Fixes: #2949
@meteorcloudy meteorcloudy mentioned this issue Sep 24, 2021
Closed
20 tasks
@meteorcloudy
Copy link
Member

@oquenchil This is also blocking bazelbuild/bazel-central-registry#7

@philwo
Copy link
Member

philwo commented Sep 24, 2021

I'd recommend to just start doing releases here as @oquenchil said with 0.x - this tells the user that there's no promise of any compatibility between the versions.

@oquenchil
Copy link
Contributor

I will take care of it next week.

@limdor
Copy link
Contributor

limdor commented Oct 13, 2021

@philwo could it be possible to have https://github.com/bazelbuild/rules_cc/releases/download/0.0.1/rules_cc-0.0.1.tar.gz also in the bazel mirror? Thanks

@dinord dinord mentioned this issue Oct 14, 2021
Merged
derekmauro pushed a commit to google/cctz that referenced this issue Oct 14, 2021
@dinord
Remove bazelbuild/rules_cc dependency (#203)
3e2b904 
* Remove bazelbuild/rules_cc dependency

The Bazel team recommends using native rules nowadays: bazelbuild/rules_cc#91 (comment)
Abseil stopped depending on `rules_cc` in abseil/abseil-cpp@b2387f0.
@philwo
Copy link
Member

philwo commented Oct 19, 2021

@limdor Uploaded!

@meteorcloudy
Copy link
Member

Looks like this issue can be closed, thanks for the effort!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@philwo @aiuto @limdor @olekw @meteorcloudy @oquenchil @catleeball